Beamforming plays an important role in maintaining a robust wireless data link. Where beamforming is utilized, link control generally defines a process and protocol (“training protocol”) that iterates through all beamforming configurations to detect the best configuration, based on the reported receiver's signal quality. This process takes a fixed minimum duration of time. For example, a typical Wireless Gigabit Alliance (“WiGig”) implementation may take up to three milliseconds, with an overall systems tradeoff of implementation complexity and power. Even for more optimized beamforming procedures, the triggering of the beamforming procedure occurs either in a predetermined period, or in response to link deterioration. Either way, this consumes higher power and imposes recovery latency.
In some cases, the beamforming protocol must be reattempted during device operation. During the training protocol, no user data can be transmitted, which results in a high risk of user-observable latency. Real-time sensitive data, such as video or graphics streaming, suffer from such latency. In the case of a head mounted display, a streaming display video is tightly constrained with respect to latency and jitter as key performance indicators (KPI). For example, the key performance indicator for latency may be less than 10 milliseconds, and the key performance indicator for jitter may be less than 4 milliseconds.
In light of these constraints, there is a need to limit the frequency of the training protocol, and to increase the speed of reaching a satisfactory beamforming setting. Prior efforts have been aimed at identifying beamforming settings that are unlikely to be satisfactory, and removing same from the possible iterations of beamforming settings that will be attempted during a training protocol. Yet, even where potentially undesirable beamforming settings are identified and excluded from the training protocol, a training protocol must still be implemented in response to link deterioration.